© BUNDESREPUBLIK 
DEUTSCHLAND 




© Offenlegungsschrift 
®DE 10041 310 A 1 



® 



DEUTSCHES 
PATENT- UND 
MARKENAMT 



® Aktenzeichen: 
® Anmeldetag: 
© Offenlegungstag: 



100 41310.2 
23. 8.2000 
7. 3.2002 



Int. CI. 7 : 

G 06 F 15/163 

H 03 M 7/30 «- 
H 04 L 12/16 ^ 
H 04 N 7/173 



c 
c 



u 
C 



© Anmelder: 


® Erfinder: 


Deutsche Telekom AG, 53113 Bonn, DE 


Kirchherr, Ralf, 63225* Langen, DE; Stegmann, 


Joachim, 64289 Darmstadt, DE 




(§) Fur die Beurteilung der Patentfahigkeit in Betracht 




zu ziehende Druckschriften: 




US 60 44 397 A 




US 60 06 241 A 




US 57 34 119 A 




US 56 89 800 A 



® 



< 

o 

CO 

5 

o 
o 

LLI 
Q 



,24 



25 



26 



27 



,29 



,30 



,31 



,32 



.35 



Die f olgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

Verfahren zum Plattformunabhangigen Streaming von Multimedia-lnhalten fiir IP-basierte Netze 

Das erfindungsgemaSe Verfahren mit Hilfe des Einsat- 
zes der Java-Technologie macht die Multimedia-lnhalte 
uber jedes bejiebig e Java -fahige_End,qerat abrufbar. Die 
Decodierung der komprSmierten Multimedia-lnhalte uber- 
nimmt dabei ein Java-Applet, das automatisch von einem 
Web-Browser gestartet wird. Die Komprimierung der Da- 
ten erfolgt mit Codierverfahren, die zum codieren der Da- 
ten nur eine geringe Komplexitat benotigen. Der Nutzer 
hat stets die aktuellste Softwa reversion zur Verfugung, da 
der eigentliche Player, das heifit das Applet jedesmal mi- 
tubertragen wird. Der Benutzer braucht daher keinerlei 
Hard- oder Software-lnstallationen durchzufuhren, sofern 
er nur einen kompatiblen Java-fahigen Browser besitzt. 
Damit wird ein niedrigschwelligerZugang zu multimedia- 
len Inhalten gewahrt und ermoglicht. Es sind dargestellt 
die Audio-lnhalte 24, die Video-lnhalte 25, die Bilder und/ 
oder Graphiken 26, die Textinformatlonen 27 und die 
URLs (Links) 28. Jedem dieser bestimmte Inhalte, Infor- 
mationen usw. darstellende Kastchen 24 bis 28 ist ein spe- 
zieller Codierer 29 bis 33 nachgeordnet, den ein Multiple- 
xer 34 nachgeordnet ist, der zum Aufteilen der Mulitme- 
dia-lnhalte in einzelne inhaltliche Abschnitte dient. Am 
Ausgang des Multiplexers 34 erscheinen die komprimter- 
ten Multimedia-Oaten 35, wobei alle Inhatte sequentiell 
multiplex! sind, je ein Datensatz pro Abschnitt; aufierdem 
entstehen am Ausgang des Multiplexers 34 Stcucrinfor- 
mationen 36 uber die einzelnen Multimedia-Elemente 
und zwar ... 
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Beschreibung 



[0001] Die Erfindung betrifft ein Verfahren zum platt- 
formunabhangigen Streaming von Multimedia-Inhalten fur 
IP-basierte Netze mittels Java-Tech nologie nacb dem Ober- 
begriff des Patentanspruchs 1 und/oder des Patentanspruchs 
9. 

[0002] Streaming-Technologien bzw. Verfahren fiir IP-ba- 
sierte Anwendungen im Internet bzw. Intranet sind grund- 
satzlich bekannt und ermoglichen es dem Nutzer, beliebige 
Multimedia-Inhalte quasi kontinuierlich zu iibertragen, so 
daB die Inhalte schon wahrend der tJbermittlung prasentiert 
werden konnen, ohne vorher diese vollstandig herunterladen 
zu miissen. Die bekannten Streaming- Verfahren benutzen 
dazu sogenannte Plug-Ins, die auf dem Rechner zuvor in- 
stalliert werden. Dies ftthrt dazu, daB der Nutzer stets die 
neueste Version der Plug-Ins bereithalten muB, urn die In- 
halte abrufen zu konnen. Der damit verbundene Aufwand 
verhindert eine starkere Verbreitung der Inhalte. Die Instal- 
lation von Software eventuell sogar unbekannter Herkunft, 
widerspricht auBerdem dem Sicherheitsbediirfnis vieler An- 
wender. 

[0003] Derartige Streaming-Technologien fiir Multime- 
dia-Anwendungen sind zum Beispiel in den PCT Patentan- 
meldungen W097/31445 und WO99/10836 grundsatzHch 
beschrieben. AuBerdem sind unter WWW.Emplaz.COM/ 
about/about-04.html von Geointeractive Media Group Ltd. 
grundsatzliche Vorschlage fiir Losungen dieser Art mittels 
Java-Technologie angegeben. Das darin angegebene Verfah- 
ren kommt insbesondere ohne die sonst erforder lichen vie- 
len Plug-Ins aus. 

[0004] AUerdings sind die bekannten Streaming- Verfah- 
ren hauptsachiich auf Video-Darstellungen beschrankt, die 
dann aufgrund der verfugbaren Bandbreite nur eine geringe 
, Bild- und Audioqualitat aufweisen. 

j [0005] Der Erfindung liegt die Aufgabe zugrunde, ein Ver- 
I fahren zum plattformunabhangigen Streaming von Multi- 
\ media-Inhalten fur P-basierte JNetze mittels Java-Technolo- 
\ gie zu schaffen, so das die Multimedia-Inhalte uber jedes be- 
jliebige Java-fahige Endgerat abgerufen werden konnen, das 
die Decodierung der komprimierten Multimedia-Inhalte 
durch ein Java-Applet ubernommen werden soil, das auto- 
matisch von einem Web-Browser gestartet werden kann, das 
es auBerdem ermdglicht, daB die Komprimierung der Daten 
mit Codierverfahren erfolgt, die zum Decodieren der Daten 
nor eine geringe Komplexitat benotigen und das sicherstellt, 
daB der Nutzer stets die aktuellste Softwareversion zur Ver- 
fugung hat. 

[0006] Die erfindungsgemaBe Losung der Aufgabe ist im 
Kennzeichen des Patentanspruchs 1 charakterisiert. Weitere 
Losungen der Aufgabe und Ausgestaltungen sind in den 
Kennzeichen der Patentanspriiche 2 bis 11 charakterisiert. 
[0007] Durch das erfindungsgemaBe Verfahren mit Hilfe 
des Einsatzes der Java-Technologie sind die Multimedia-In- 
halte uber jedes beliebige Java-fahige Endgerat abrufbar. 
Die Decodierung der komprimierten Multimedia-Inhalte 
iibemimmt dabei ein Java-Applet, das automatisch von ei- 
nem Web-Browser gestartet wird. Die Komprimierung der 
Daten erfolgt mit Codierverfahren, die zum Codieren der 
Daten nur eine geringe Komplexitat benotigen. Der Nutzer 
hat stets die aktuellste Softwareversion zur Verfugung, da 
der eigentliche Player, das heiBt das Applet jedesmal mitub- 
ertragen wird. Der Benutzer braucht daher keinerlei Hard- 
oder Soflware-Installationen durchzufuhren, sofem er nur 
einen kompatiblen Java-fahigen Browser besitzt. Damit 
wird ein niedrigschwelligerZugang zu muilimcdialen Inhal- 
len gewahrt und ermbglicht. 

10008] Zudem konnen zum Abrufen der Information auch 



alternative Intemet-Endgerate, wie zum Beispiel 
Screenphones, die normalerweise keine Installation von 
Plug-Ins zulassen, verwendet werden, sofern diese den Java- 
Standard unterstiitzen. Aufgrund des Java-Sicherheitskon- 

5 zepts, zum Beispiel Sandbox-Modell, ist ein ungewunschter 
Zugriff auf sicherheitsrelevante Systemressourcen weitge- 
hend ausgeschlossen. Mit diesem Streaming- Verfahren kon- 
nen sowohl Audio-, Video- als auch einzelne Bildinhalte 
^oder Texte iibertragen werden. Durch eine flexible Kombi- 

to nation dieser Multimedia-Inhalte wird es einem Anbieter 
(Content-Provider) ermbglicht, die fiir seine Zwecke geeig- 
neten DarsteUungsjpaaen auswahlen zu konnenjj. 
[0009] Bei vielen Anwendungen sind zum Beispiel hoch- 
qualitative Sequenzen von Einzelbildern vorteilhafter als 

15 Videodarstellungen bei gleicher Bitrate, die dann nur eine 
maBige Bildqualitat erlauben. 
[0010] Der Player ist als Java-Applet realisiert. 
[0011] Verschiedene fiir die jeweilige Bitrate optimierte 
Schmalband-Codierverfahren mit geringer Komplexitat auf 

20 Decoderseite (CELP- bzw. Waveform-Coder) werden be- 
reitgestellt. 

[0012] Es sind flexibel kombinierbare Multimedia-Ele- 
mente, wie zum Beispiel Audio-Signale, Bewegbilder, Ein- 
zelbilder/Graphiken, Text, URLs-Links, ohne weiteres mog- 
25 lich, wobei die Konfiguration iiber Applet-TAG-Parameter 
erfolgt 

[0013] Es besteht die Navigationsmdglichkeit zwischen 
den einzelnen Inhalten durch Gliederung in Abschnitte. Die 
Auswahl erfolgt uber Standard-Graphik-Elemente, wie zum 
30 Beispiel Listen oder Auswahlboxen. 

[0014] t)ber die Schatzung der vorhandenen Bitrate er- 
folgt eine automatische Adaption und Auswahl der Codier- 
verfahren. 

[0015] Das Verfahren ist auch bei Vorhandensein von Fi- 
35 new all/Proxy durch Unterstutzung von HTTP-Streaming 
einsetzbar. Die Multimedia-Daten werden in Form einer 
HTTP-Response tibertragen. 

[0016] AuBerdem erfolgt die Einteilung der zur decodie- 
renden Bildelemente in kleinere Tfeilbiider, um eine gleich- 

40 maBigere Verteilung der vorhandenen Rechenzeit auf die 
einzelnen Threads realisieren zu konnen. 
[0017] Fiir die Kornprimierung der Multimedia-Inhalte, 
insbesondere der Audio-Inhalte, werden komplexitatsarme 
Codierverfahren verwendet, die beim Decoder sowohl in 

45 Bezug auf ProgrammcodegrbBe als auch in Bezug auf die 
benbtigte Rechenleistung nur geringe Anforderungen stel- 
len und trotzdem eine befriedigende bzw. gute Audioqualitat 
liefem. Die Komplexitat des Encoders ist dabei von unterge- 
ordneter Bedeutung, da die Kompression der Inhalte vom 

50 Inhalte-Anbieter durchgefiihrt wird. 

[0018] Um auch bei unterschiedlichen Netzanbindungen 
eine moglichst hohe Audioqualitat erzielen zu konnen, wer- 
den mehrere unterschiedliche Codierverfahren angeboten, 
die auf die jeweilige Bitrate optimiert sind. Niederratige 

55 Sprach-Codes nach dem CELP- Verfahren ennoglichen auch 
eine Ubertragung von Sprachsignalen bei schlechter Netz- 
anbindung. Gleichzeitig ist die Komplexitat der Decoder bei 
diesem Verfahren deutlich geringer als die der zugehorigen 
Encoder. 

60 [0019] Fiir die Ubertragung von Sprach- und Musiksigna- 
len bei hoheren Bitraten werden Waveform-Coder einge- 
setzt. Durch Verwendung von Embedded-Coding-Technolo- 
gien kann die Decodierung besonderes effizient gestaltet 
werden. 

65 [0020] Die Audio- und Video-Daten werden zu einzelnen 
Rahmen konstanter Zeitdauer zusarninengcfaBi, die dann 
einzeln iibertragen und nacheinandcr im Client decodiert 
werden. 
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[0021] Weitere Multimedia-Elemente, wie zum Beispiel 
Bilder, Texte oder URLs, werden in den Bitstrom der Audio- 
/Video-Daten multiplext, so daB diese zu den jeweils ge- 
wiinschten Zeitpunkten zur Verfugung stehen. Ein Client 
muB dahe mur einen einzifle " nflter^stmm einlesen. aus dem 
dann die jeweiligen Multimedia-Elemente decodiert werden 
konnen. Dazu wird ein spezieller Datensalz mit Steuerinfor- 
mationen erstellt, der Angaben zu dem Zeitpunkt, der Dauer 
und der GroBe der einzelnen Multimedia-Elemente enthalt 
[0022] Weitere Vorteile, Merkmale und Anwendungs- 
mogiichkeiten der vorliegenden Erfindung, insbesondere 
des plattformunabhangigen Streamings von Multimedia-In- 
halten fur IP-basierte Netze mittels Java-Tech nologie, erge- 
ben sich aus der nachfolgenden Beschreibung In Verbindung 
mit den in der Zeichnung dargestellten Ausfuhrungsbeispie- 
len. 

[0023] Die Erfindung wird im folgenden anhand von in 
der Zeichnung dargestellten Ausfuhrungsbeispielen naher 
beschrieben. In der Beschreibung, in den Patentanspriichen, 
der Zusammenfassung und in der Zeichnung werden die in 
der hinten angefuhrten Liste der Bezugszeichen verwende- 
ten Begriffe und zugeordneten Bezugszeichen verwendet. 
[0024] In der Zeichnung bedeuten: 
[0025] Fig, 1 eine Generierung der Multimedia-Inhalte; 
[0026] Fig, 2 ein Beispiel fur den Aufbau einer graphi- 
sphen Benutzerschnittstelle (GUI) des Players; 
[0027] Fig, 3 ein detaillierteres RuBdiagramm; 
[0028] Fig, 4 eine beispielsweise Unterteilung eines Ein- 
zelbildes in mehrere Teilbilder und 
[0029] Fig. 5 eine Darstellung zur Bitratenschatzung. 
[0030] In Fig. 1 ist prinzipiell die Generierung der Multi- 
media-Inhalte und deren Codierung zur Komprimierung der 
Inhalte und Informationen sowie die Aufteilung der Multi- 
media-Inhalte in einzelne inhaltliche Abschnitte gezeigt 
Fur die Codierung der Bildinhalte werden Bildcodierverfah- 
ren verwendet, die auf der Decoderseite nur geringe Anfor- 
derungen in Bezug auf ProgrammcodegroBe und Rechenlei- 
stung stellen bzw. bereits in der Java-Virtuell-Maschine im- 
plementiert sind. Im Strukturbild zur Generierung der Mul- 
timedia-Inhalte nach Fig. 1 sind dargestellt die Audio-In- 
halte 24, die Video-Inhalte 25, die Bilder und/oder Graphi- 
ken 26, die Textinformationen 27 und die URLs (Links) 28. 
Jedem dieser bestimmte Inhalte, Informationen usw. darstel- 
lende Kastchen 24 bis 28 ist ein spezieller Codierer 29 bis 33 
nachgeordnet, namlich 

- ein Codierer 29 zur Komprimierung der Audio-In- 
halte (Codierung erfolgt rahmenweise) 

- ein Codierer 30 zur Komprimierung der Video-In- 
halte (Codierung erfolgt rahmenweise) 

- ein Codierer 31 zur Komprimierung der Bild-Inhalte 

- ein Codierer 32 zur Komprimierung der Textinfor- 
mationen und 

- ein Codierer 33 zur Komprimierung der URLs. 

[0031] Den Codierem 29 bis 33 ist ein Multiplexer 34 
nachgeordnet, der zum Aufteilen der Multimedia- Inhalte in 
einzelne inhaldiche Abschnitte dient. 
[0032] Am Ausgang des Multiplexers 34 erscheinen die 
komprimierten Multimedia-Daten 35, wobei alle Inhalte se- 
quentiell multiplext sind, je ein Datensalz pro Abschnitt. 
[0033] Aufierdem entstehen am Ausgang des Multiplexers 
34 Steuerinformationen 36 iiber die einzelnen Multimcdia- 
Elernenle und zwar je ein Datensatz pro Abschnitt. Die 
Steuerinformationen 36 enthalten Informationen iiber den 
Zeiipunkt, die Dauer und die GroBe der einzelnen Multime- 
dia-Elemente. Ebenfalls enthalten sind konstanle Header- 
Daten fur einzelne Medien formate (zuin Beispiel JPEG), die 



sich in dem jeweiligen Abschnitt nicht andern und daher 
nicht fur jeden Rahmen neu iibertragen werden mussen. 
[0034] Im vorliegenden Beispiel ist das Applet vollstandig 
in Java realisiert, um so die Plattformunabhangigkeit der 
5 Anwendung zu gewahrleisten. Um auch eine Kompatibilitat 
mit aiteren Web-Browsern zu gewahrleisten wird Java 1.0 
Standard verwendet. Weitgehende Funktionen neuerer Java- 
Standards werden verwendet, wenn der Browser diese un- 
terstiitzt, ansonsten wird nur die Grundfunktionalitat zur 
10 Verfugung gestellt Das Applet fangt dabei automatisch 
Fehlermeldungen ab, die auf der Verwendung eines neueren 
(nicht unterstiitzten) Java-Standards beruhen und fuhrt statt- 
dessen alternative Programmroutinen mit eventuell einge- 
^schrankter Funktionalitat aus. 
15^0035] Die Konfiguration des Players (Applets) erfolgt. 
iiber die Applet-Tag-Parameter. Diese Konfiguration ermog- 
licht dem Inhalte-Anbieter die Anpassungen an Layout und 
Funktionalitat auf einfache Weise vornehmen zu konnen. 
[0036] Zur Konfiguration stehen fiir den Inhalt der Anbie- 
20 ter folgende Optioneh zur Verfugung: 
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- Auswahl der gewiinschten Multimedia-Elemente 
(Audio, Video, Einzelbilder, Text, URL, . . .) 

- Angabe eines Titels 

- Angabe der Bezeichnung der einzelnen Abschnitte 

- Angabe der zur Verfugung stehenden Codierverfah- 
ren mit Bezeichnung 

- GroBe der darzustellenden optischen Multimedia- 
Elemente (Video, Bilder). 
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[0037] Die Inhalte konnen zur besseren Obersicht in ein- 
zelne Abschnitte gegliedert werden. Damit wird demNutzer 
die Moglichkeit gegeben, auf die jeweiligen Abschnitte ge- 
zielt zugreifen zu konnen. Um die ProgrammcodegroBe ge- 
35 ring zu halten, werden zur Navigation Standard-Graphik- 
Elemente (Listen, Auswahlboxen, Rollbalken) verwendet. 
[0038] _Ejn Beispiel fur eine mogHche Kombinatioj uver- 
schiedener N^dmecTia-Element e ineinenxPl^ ensTinJFig. 
Jl dargestellt Dies ist auch gleichzeitig ein Beispiel fiir den 
Aufbau einer ^mphischen ^BeJuitzer^chtuttstei le (GUI) des 
Players 18 st ellt dabei das Appletfenster dar, 19 das Fenster 
fur die Video-Darstellungen, 20 das Fenster fur die Darstel- 
lung von Textinformationen (eventuell noch mit Links fiir 
weitergehende Informationen), 21 ein Fenster zur Darstel- 
lung von Einzelbildem/Bildersequenzen, zum Beispiel fiir 
• Detail-Darstellungen, 22 eine Steuerleiste mit Start, Stopp, 
Pause und Schieberegler zum "Vor- und Zuruckspulen" und 
23 eine Auswahlbox fiir die inhaltlichen Abschnitte. 
[0039] Fiir die Obertragung der Inhalte werden zwei un- 
50 terschiedliche Anwendungen unterschieden, namlich On- 
Demand-Streaming fur vorgefertigte Inhalte und Live- 
streaming. 

[0040] Zunachst soil das On-Demand-Streaming naher 
beschrieben werden. 

[0041] Dabei werden die bereitzustellenden Inhalte Of- 
fline mit einem separaten Encoder-Tool komprimiert, so daB 
vorgefertigte Inhalte entstehen, die dann jederzeit vorn Nut- 
zer abgerufen werden konnen. Die codierten Daten werden 
dabei mit Hilfe de s HTTP-Protokolls iibertragen. Es wird 
daher lediglich statischer Speicherplatz auf einem Web-Ser- 
ver benotigt, das heiSt der Betrieb eines eigenstandigen Ser- 
vers enlfallt fiir den Inhalt der Anbieter, was einen sehr gro- 
Sen Vorteil des erfindungsgemafien Verfahrens darsiellt. 
[0042] Die codierten Daten werden zu einer gemeinsamen 
65 Multimedia-Dalei zusammengefaBt, daB.^die Daiea-uber 
einen einzelnen Stream iibertragen werden konnen. Die be- 
" ndtigTen I n form at idnen" iiber Tien * Darslellungszeiipun k L so- 
wie die GroBe der einzelnen Multimedia-Elemente werden 
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^Moglichkeit bestehen, zu anderen URLs verzweigen zu kon- 
nen, zum Beispiei fur weitergehende Informalionen. 
[0055] In 12 wird die fiir die Adresse benotigte Zeichen- 
kette (GroSe ist in der Steuerdatei angegeben) Uber das Netz 
5 eingelesen und zu einer URL zusammengesetzt. Wenn der 
Anwender zu dieser Adresse verzweigen will, zum Beispiei 
durch Klicken auf ein entsprechendes Feld, kann der 
JJrowser direkt zu dieser URL wechseln^ 
/[0056] In 13 werden die codierten Audio- bzw. Videdda- 
10 ten fur die zeitliche Lange eines Rahmens iiber das Netz ein- 
gelesen und anschlieBend decodiert. 

[0057] In 14 werden die decodierten Audio/Videodaten . 
dann an einen speziellen Programm-Thread zur Ausgabe 
(Audio/Video Rendering) weitergegeben und eventuell ge- 
15 puffert, so daB bereits die Bearbeitung des nachsten Rah- 
mens beginnen kann solange noch der alte Rahmen ausge- 
geben wirdj 

[0058] IrTlS wird festgestellt, ob zu einem anderen inhalt- 
lichen Abschnitt oder zu- einer anderen Bitrate gewechselt 



dazu vorher aus der Steuerdatei eingelesenjj 
[0043] Im nachfolgenden wird anhand eines FluBdia- 
gramms nach Fig. 3 der Ablauf des On-Demand-Streaming- 
Verfahrens grundsatzlich beschrieben, wobei betont werden 
soil, daB dieser Ablauf auch grundsatzlich fur das anschlie- 
Bend beschriebene Live-Streaming gilt. 
[0044] In 1 wird das Applet geladen und gestartet Aus 
dem Applet-Tag werden die Parameter ausgelesen, die die 
gewiinschte Konfiguration des Players beschreiben. Dabei 
wird unter anderem die Art der gewiinschten Darstellung, 
wie Audio, Video, Bildersequenzen usw., sowie deren 
GroBe angegeben. 

[0045] In 2 wird die graphische Benutzerschnittstelle GUI 
in Abhangigkeit der Player Parameter aufgebaut, so daB die 
gewiinschten Multimediaelemente dargestellt werden kon- 
nen, zum Beispiei separates Fenster zur Darstellung der Bil- 
der. 

[0046] In 3 wird eine fur den entsprechenden inhaltlichen 
Abschnitt sowie fur die ausgewahlte Bitrate gultige Binar- 

datei (Steuerdatei) eingelesen, d je Tnformationen uber de n 20 werden soil. Die Steuerung erfolgt hierbei durch den An- 



Zeitpunkt, die Dauer und die GroBe der einzelnen Multime- 
dia-Elemente enthalt; beispielsweise wann soil fur wie lange 
ein entsprechendes Bild mit bestimmter PixelgroBe ange- 
zeigt werden. Ebenfalls ent halten sind konstante l^eadaF* 



die sich wjJena.Abr._25 



Osier* fur einzelne Medien^ 



schnitt nicht a ndern u nddahermcht fur jeden Rahmen neu 
Jibertragen werden mtissen... 

[0047] In 4 soli im Stream weiter fortgefahren werden 
oder der Anwender will an eine bestimmte S telle im Stream 



wender iiber die Schnittstelle GUI. 
[0059] In 16 wird festgestellt, ob noch weitere Multime- 
dia-Daten bzw. Rahmen vorhanden sind, die prozessiert und 
ausgegeben werden konnen und 

in 17 wird der Multimedia-Stream vollstandig ausgegeben. 
Das Applet wird angehalten bzw. beendet 
[0060] Die Kommunikation zwischen Client und Web- 
Server kann von Seiten des Clients aus mit einer Socket- 
Verbindung oder mit einer "URL-Connection" erfolgen. Er- 



springen, zum Beispiei Vor-/Rtickspulen. Diese Information 30 sterer Fall ist haufig giinstiger, um Optionen des HTTP-Re- 

wird iiber die graphische Benutzerschnittstelle ubermittelt, quests direkt beeinflussen zu konnen, zum Beispiei Option 

zum Beispiei durch nicht hier dargestellte Schieberegler. "Byte Ranges" wird fur Punkt bzw. Schritt 5 in Fig. 3 ver- 

[0048] Bei 5 wird rait Hilfe der in der Steuerdatei enthal- wendet Im Falle einer vorhandenen Firewall bzw. Proxy er- 

tenen Informationen der Offset in Byte berechnet, an dem folgt die Verbindung automatisch iiber die URL-Connection 

sich die gewiinschten Daten innerhalb der Multimedia-Datei 35 (im Java-Syntax heiBt die Klasse URL-Connection). Die au- 



befinden, wenn die Wiedergabe des Streams an einer belie- 
bigen S telle beginnen soli. Die codierten Multimedia-Daten 
(rahmenweise komprimierte Inhalte) werden dann iiber ei- 
nen HTTP-Request erst ab der durch den Offset spezifizier- 
ten Stelle angefordert, so daB die Daten, die vorhergehende 40 
und damit nicht gewiinschte Inhalte beschreiben, nicht un- 
notig iiber das Netz geladen werden miissen. 
[0049] Die Inhalte werden zeitlich rahmenweise (typisch 
< 1 Sekunde) eingelesen, prozessiert und ausgegeben. Die 
Schritte 6 bis 14 beschreiben dabei einen Zyklus, wie er ein- 
mal pro Rahmen durchlaufen wird, namlich wie folgt: 
GemaB 6 werden aus der Steuerdatei die fur diesen Zeit- 
punkt darzustellenden Multimedia-Elemente ermittelt. Zum 
Beispiei sollen neue Bild- oder Textinformationen darge- 
stellt werden? 

[0050] In 7 wird festgelegt, ob zu diesem Zeitpunkt (Rah- 
men) ein neues Bild dargestellt werden soli. 
[0051] GemaB 8 werden die benotigten Bilddaten (GroBe 
in der Steuerdatei angegeben) iiber das Netz eingelesen und 
decodiert. Dabei werden fur die Decodierung (typischer- 
weise JPEG-Decodierung) die Bilddaten in kleinere Teiibil- 
der aufgeteilt, um so die Rechenleistung besser zwischen 
den einzelnen Programm-Threads aufteilen zu konnen. Die 
einzelnen Teilbilder werden gesammelt und dann schlieB- 
lich gemeinsam iiber die Schnittstelle GUI dargestellt, wie 
spater noch beschrieben wird. 

[0052] In 9 wird festgestellt, ob zu diesem Zeitpunkt 
(Rahmen) eine Textin formation dargestellt werden soil. 
[0053] In 10 wird die Zeichenkette (GroSe ist in der Steu- 
erdatei angegeben) iiber das Netz eingelesen und decodiert. 
Die Texlin formation wird anschlieBend uber die Schnitt- 
stelle GUI angezeigt. 

[0054] GemaB 11 soil zu diesem Zeitpunkt (Rahmen) die 
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tomatische Detection der erforderlichen Verbindungsart er- 
folgt analog dem Live-Streaming- Verfahren das nachfol- 
gend naher beschrieben wird. 

[0061] Bei Live-Inhalten miissen die Signaldaten wie Au- 
dio-, Video- und Bildinhalte in Echtzeit codiert werden. Die 
Decodierung nimmt dabei ein spezieller Server vor, der die 
codierten Multimedia-Inhalte dann an die angeschlossenen 
Clients, das heiBt Applets, iibermittelt. 
[0062] In diesem Fall konnen die Daten uber UDP, TCP 
(Socket)- oder HTTP-Verbindungen iibertragen werden. 
[0063] Die Unterstutzung von HTTP- Streaming ermog- 
licht den Zugriff auf die Multimedia-Inhalte auch uberNetz- 
grenzen hinweg, wie zum Beispiei Firewall oder Proxy, da 
keine separate Socketverbindung aufgebaut werden muB. 
Dabei werden die codierten Daten abschnittweise aus einem 
Klassenobject vorniyp URL-Connection eingelesen. Diese 
Verbindungsart ist immer dann notwendig, wenn bei einer 
eventuell vorhandenen Firewall nur der WWW-Dienst frei- 
geschaltet ist. Der Server wartet in diesem Fall aktiv an dem 
normalerweise fur WWW-Abfragen benutzten Port auf ein- 
gehende HTTP-Anfragen. Der Client erzeugt dann iiber eine 
URL-Connection eine Anfrage zu einer bestimmten URL, 
die vom Server als Anfrage fur die Echtzeitdaten erkannt 
wird. Der Server kann daraufhin in Form einer HTTP-Re- 
sponse die codierten Daten ubermitteln. Wenn sich zwi- 
schen dem Server und dem Client keine Netziibergange be- 
finden, sind andere Verbindungsarten, wie zum Beispiei 
TCP oder UDP oftmals vorteilhafter. Die codierten Daten 
werden in diesen Fallen iiber die jcweiligen Verbindungs- 
schnittstellen ausgegeben. 

[0064] Daher wird beirn Starten des Applets zunachst ver- 
sucht, eine solche UDP- bzw. TCP- Verbindung aufeubauen. 
[0065] Damit das System nicht unnotig lange blockiert 
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wird, wenn dieser Verbindungstyp nicht moglich sein solite, 
erfolgt der Verbindungsaufbau in einem eigenen Thread, der 
nach einer festgelegten Zeitspanne von wenigen Sekunden 
abgebrochen wird, wenn bis dahin keine Verbindung zustan- 
degekommen ist. In diesem Fall erfolgt die Ubertragung mit 
Hilfe des HTTP-Protokolls. Damit ist sichergestellt, daB das 
System in jedem Fall selbstandig den geeigneten Verbin- 
—dungstyp herstellt. 

"[0066] Der Programmablauf auf Client-Seite ist damit 
prinzipiell identisch mit dem Programmauflauf bei On-De- 
mand-Streaming. Der Unterschied besteht nur darin, daB die 
Daten, namlich Multimedia- und Steuerdaten nicht aus ab- 
gespeicherten Dateien eingelesen werden sondern quasi 
kontinuierlich vom Server iibertragen werden. Mit anderen 
Worten heiBt das, dafi der Server die Daten rahmenweise in 
Echtzeit prozessiert und zwar so wie sie auch vom Client 
rahmenweise eingelesen werden. Prinzipiell ist diese Strea- 
ming-Variante keineswegs auf Live-Inhalte beschrankt Die 
durch den Einsatz einer speziellen Server-Software beding- 
ten Vorteile, zum Beispiel ttbertragung mit UDP bzw. TCP, 
automatische Bitratenschatzung, konnen auch fur vorgefer- 
tigte Inhalte genutzt werdenjj 

[0067] Im nachfolgenden wird die Aufteilung der Rechen- 
leistung auf die einzelnen Programmthreads/Bilddarstellung 
beschrieben. 

[0068] Viele Implementierungen der Java-Virtuell-Ma- 
schine in den verschiedenen Browsern erlauben es nicht, die 
einzelnen Threads des Applets unterschiedlich zu priorisie- 
ren. Es ist jedoch gerade bei der Audio- Ausgabe sicherzu- 
stellen, daB die Programm-Routinen, die fur die Ausgabe 
des Audiosignals verantwortlich sind, rechtzeitig ausgeflihrt 
werden, damit die Audio- Ausgabe nicht durch kurze Aus- 
setzer gestbrt wird. Damit ein einzelner Thread den Pro- 
grammlauf nicht zulange blockiert, wird der Programmalgo- 
rithmus in einzelne kleinere Programmroutinen unterteilt, 
wobei jeweils am Ende einer Routine die Programmausfiih- 
rung an einen anderen Thread ubergeben wird. 
[0069] Urn auch groBformatige Bilder als Multimedia-In- 
halte prasentieren zu konnen, darf die Programmausfuhrung 
nicht zu lange durch die benotigte Decodierung des Bildfor- 
mats blockiert werden. Deshalb wird das darzustellende 
Bild in kleinere Einzelbilder aufgeteilt, die dann nacheinan- 
der dargestellt werden konnen, so daB zwischen der Deco- 
dierung der einzelnen Teilbilder jeweils kurzzeitig die Pro- 
grammausfuhrung an andere Threads ubergeben werden 
kann. Diese Aufteilung eines Bildes, beispielsweise in vier 
Teilbilder, ist in Fig. 4 dargestellt. 

[0070] In Fig. 4 ist das Bild in ein erstes Teilbild 37, ein 
zweites Teilbild 38, ein drittes Teilbild 39 und ein viertes 
Teilbild 40 aufgeteilt, die dann nacheinander dargestellt 
werden konnen, so daB zwischen der Decodierung der ein- 
zelnen Teilbilder 37 bis 40 jeweils kurzzeitig die Program- 
mausfuhrung an andere Threads ubergeben werden kann. 
[0071] Im nachfolgenden wird nun eine automausche Bi- 
tratenadaption beschrieben. 

[0072] Wenn wie im Fall des Live-Streamings eine spe- 
zielle Serversoftware verwendet wird, kann auf der Client- 
Seite eine automatische Adaption der verwendeten Codier- 
verfahren, sowohl Audio als auch Video, erfolgen, indem 
die zur Verfugung stehende Bitrate geschatzt wird. 
[0073] Die automatische Bitratenadaption beruht auf einer 
Schatzung der zur Verfugung stehenden Bandbreite. Ent- 
sprechend dieses Schatzwertes wird ein passendes Codier- 
verfahren ausgewahlt, dessen Bitrate mit der vorhandenen 
Bandbreite iibertragen werden kann. 

[0074] Eine gceigncie Schatzung der bei der vorhandenen 
Netzanbindung zur Verfugung stehenden Bitrate kann durch 
die Ubertragung eines Dalenblocks bestiminter GroBc erfol- 



gen, bei gleichzeitiger Bestimmung der fur die t)bertragung 
benotigten Zeit. Der Bitraten-Schatzwert errechnet sich 
dann aus dem Quotienten zwischen Anzahl der iibertrage- 
nen Bits und der dafur benotigten Zeit L 

5 [0075] Um hier verlassliche Schatzwerte erzielen zu kon- 
nen, diirfen die ubertragenen Datenblocke jedoch nicht zu 
klein sein, da sich im anderen Fall kurzzeitige tJbertra- 
gungsschwankungen nicht herausmitteln bzw. die Zeitmes- 
sungen im Verhaltnis zur DatengroBe zu ungenau werden. 

10 [0076] Um eine genauere Bitratenschatzung zu ermogli- 
chen, werden daher N Datenblocke (Rahmen) zur Bitraten- 
bestimmung gleichzeitig iibertragen, um so die Obertra- 
gungsdauer einer groBeren Datenmenge messen zu konnen. 
[0077] Am Server muB daher ein entsprechender Puffer 

15 vorhanden sein, in dem die Datenblocke von der Echtzeit- 
Signalquelle zwischengespeichert werden. Aus diesem Puf- 
fer konnen dann die einzelnen Datenblocke zum Client 
iibertragen werden. 

[0078] Die Bitratenschatzung bzw. die zugehorige Adap- 
20 tion des Codierverfahrens erfolgt nur alle K Sekunden, um 
so auch ein zu haufiges Umschalten zwischen den verschie- 
denen Codierem ausschlieBen zu konnen. Das heiBt mit an- 
deren Worten, daB der Client nach dem Zeitintervall K ge- 
maB Fig. 5 zusatzlich zu den regelmaBig ubertragenen Au- 
25 dioblocken N weitere Audiodatenblocke anfordert Die Zeit 
t, die der Client dann benotigt, diese Daten einzulesen und 
zu decodieren, dient als Grundlage zur Berechnung des Bit- 
raten-Schatzwertes. 

[0079] Nach der Obertragung der N Audioblocke unter- 
30 bricht der Server dann die tJbertragung fur weitere Audio- 
Blocke, bis der Client die gepufferten N Audioblocke abge- 
spielthat. 

[0080] Die zur "Obertragung verwendeten Codierverfahren 
bestimmen sich durch den Schatzwert der Bitrate. Dabei 

35 wird dasj enige Codierverfahren ausgewahlt, dessen Nettobi- 
trate noch mit der geschatzten Netzbandbreite iibertragen 
werden kann. Wenn dabei ein anderes Codierverfahren er- 
mittelt wird als das, das zur Zeit fur die "Obertragung ver- 
wendet wird, dann schickt der Client einen entsprechenden 

40 Befehl zum Server der daraufhin das Codierverfahren um- 
schaltet. 

[0081] Die Schwellen fur die Umschaltung zwischen den 
Codierverfahren sollten grofiziigig bemessen sein, das heiBt 
erst wenn die geschatzte Bitrate deutlich iiber der fur die je- 

45 weiligen Codierverfahren benotigten Nettobitrate liegt, 
kann dieser Codierer fur die Obertragung verwendet wer- 
den. Dadurch ist sichergestellt, daB auch bei kleineren 
Schwankungen in der Obertragungsbandbreite bzw. bei un- 
genauer Schatzung der Bitrate eine stabile Obertragung der 

50 Multimedia-Daten erfolgt bzw. moglich ist. 

Liste der Bezugszeichen 

I Applet laden, starten und Parameter auswerten 
55 2GUIaufbauen 

3 Steuerdatei einlesen 

4 Im Stream springen? 

5 Offset berechnen und Multimedia-Datei an entsprechen- 
der Stelle anfordern 

60 6 Aussteuerdateiart der Multimedia-Elemente fur diesen 
Rahmen berechnen 

7 Feststellen ob Bild 

8 Bilddaten auslesen, decodieren und darslellen 

9 Feststellen ob Text 

65 10 Textinformation auslesen und darslellen 

II Feststellen, ob URL 

12 Adresse auslesen und bei Klick zu dieser URL wechseln 

13 Audio-/Videorahmen einlesen und decodieren 
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14 Thread zur Ausgabe der Audio- Videoinhalte 

15 Feststellen ob neuer Abschnitt/oder neue Bitrate 

16 Feststellen ob weitere Daten vorhanden 

17 Ertde 

18 Applet-Fenster 

19 Fenster fur Video-Darstellungen 

20 Fenster fur Text-Informationendarstellung 

21 Fenster fur Einzelbilder/Bildsequenzendarstellungen 

22 Steuerleiste 

23 Auswahlbox fur inhaltliche Abschnitte 

24 Audioinhalte 

25 Videoinhalte 

26 Bilder, Graphiken 

27 Textinformationen 

28 URLs 

29 Codierer zur Komprimierung der Audioinhalte 

30 Codierer zur Komprimierung der Videoinhalte 

31 Codierer zur Komprimierung der Bildinhalte 

32 Codierer zur Komprimierung von Textinformationen 

33 Codierer zur Komprimierung der URLs 

34 Multiplexer 

35 komprimierte Muitimedia-Daten 

36 Steuerinformationen 

37 erstes Teilbild 

38 zweites Teilbild 

39 drittes Teilbild 

40 viertes Teilbild 

Patentanspriiche 

1. Verfahren zum plattformunabhangigen Streaming 
von Multimedia-Inhalten fur IP-basierte Netze mittels 
Java-Technik, insbesondere fur das Internet oder Intra- 
net, bei dem Multimedia-Inhalte quasi kontinuierlich 
iibertragen werden konnen, so daB Inhalte schon wah- 
rend der t)bermittlung prasentiert werden konnen ohne 
daB diese bereits vollstandig heruntergeladen sind, da- 
durch gekennzeichnet, 

daB die Decodierung von komprimierten Multimedia- 
Inhalten rnit Hilfe eines Java- Applet erfolgt, das auto- 
matisch von einem Web-Browser gestartet wird; 
daB die Multimedia-Elemente wie Audiosignale, Be- 
wegtbilder, Einzelbilder/Graphiken, Text, URLs/Links 
flexibel kombinierbar sind und die Konfiguration uber 
Applet-Tag-Parameter erfolgt und 
daB eine automatische Adaption und Auswahi der Co- 
dierverfahren iiber eine Schatzung der jeweils vorhan- 
denen Bitrate erfolgt. 

2. Verfahren nach Patentanspruch 1, dadurch gekenn- 
zeichnet, daB die Komprimierung der Daten mit Co- 
dierverfahren erfolgt, die zum Decodieren der Daten 
nur eine geringe Komplexitat benotigen, insbesondere 
fur die jeweilige Bitrate optimierte Schmalband-Co- 
dierverfahren mit geringer Komplexitat auf Decoder- 
Seite, wie zum Beispiel CLP- bzw. Waveform-Coder 
und dadurch, daB das Java-Applet als der eigendiche 
Player jedesmal mitiibertragen wird. 

3. Verfahren nach einem der vorhergehenden Patent- 
anspriiche, dadurch gekennzeichnet, 

daB Internet-Endgerate, die den Java-Standard unter- 
stutzen, zum Abrufen der Informationen verwendet 
werden und 

daB mit dem Streamingverfahren sowohl Audio-, Vi- 
deo- als auch einzelne Bild-Inhalte oderTexte iibertra- 
gen werden. 

4. Verfahren nach einem der vorhergehenden Patent- 
anspriichc, dadurch gekennzeichnet, 

daB eine Navigalionsntoglichkeit zwischen den cinzel- 
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nen Inhalten durch Gliederung in Abschnitte erfolgt 
und 

daB die Auswahi iiber Standardgraphikelemente, zum 
Beispiel Listen oder Auswahlboxen erfolgt. 

5. Verfahren nach einem der vorhergehenden Patent- 
anspriiche, dadurch gekennzeichnet, daB die Multime- 
dia-Daten in Form einer HTTP-Response iibertragen 
werden. 

6. Verfahren nach Patentanspruch 5, dadurch gekenn- 
zeichnet, daB bei Vorhandensein von geschiitzten An- 
wendungen, Netzen oder Teilen von Netzen, wie zum 
Beispiel von Firewall, Proxy das plattformunabhangige 
Streaming von Multimedia-Inhalten in IP-basierten 
Netzen durch die Unterstiitzung von HTTP- Streaming 
erfolgt 

7. Verfahren nach einem oder mehreren der vorherge- 
henden Patentanspriiche, dadurch gekennzeichnet, daB 
zur gleichmaBigeren Verteilung von vorhandener Re- 
chenzeit auf einzelne Threads eine Einteilung der zu 
decodierenden Bildelemente in kleinere Teilbilder (37 
bis 40) erfolgt 

8. Verfahren nach einem oder mehreren der vorherge- 
henden Patentanspriiche, dadurch gekennzeichnet, 
daB bereitzustellende Inhalte offline mit einem separa- 
ten Encoder-Tool komprimiert werden und 

daB die codierten Daten dabei mit Hilfe des HTTP-Pro- 
tokolls iibertragen werden, wobei die codierten Daten 
zu einer gemeinsamen Multimedia-Datei zusammen- 
gefaBt werden, so daB die Daten iiber einen einzelnen 
Stream iibertragen werden und die benotigten Steuerin- 
formationen iiber den Darstellungszeitpunkt sowie die 
GroBe der einzelnen Multimedia-Elemente aus einer 
Steuerdatei Vorher eingelesen werden. 

9. Verfahren zum plattformunabhangigen Streaming 
von Multimedia-Inhalten fur IP-basierte Netze mittels 
Java-Technik, insbesondere bei On-Demand-Strea- 
ming, dadurch gekennzeichnet, 

daB (1) ein Java-Applet als Player geladen und gestar- 
tet wird, 

daB aus dem Java-Applet-Tag Parameter ausgelesen 
werden, die die gewiinschte Konfiguration des Players 
beschreiben, 

daB (2) eine graphische Benutzerdarstellung (GUI) in 
Abhangigkeit der Playerparameter aufgebaut wird, 
daB (3) eine fur den entsprechenden inhaltlichen Ab- 
schnitt und die ausgewahlte Bitrate gultige Steuerdatei 
eingelesen wird, die Informationen iiber den Zeitpunkt, 
die Dauer und die GroBe der einzelnen Multimedia- 
Elemente enthalt, 

daB (4) eine Abfrage erfolgt, ob im Stream weiter fort- 
gefahren werden soli oder der Anwender an eine be- 
stimmte S telle im Stream springen will, wobei diese In- 
formation iiber eine graphische Benutzerschnittstelle 
ubermittelt wird, 

daB (5) bei Wiedergabe des Streams an beliebiger 
S telle mit Hilfe der in der Steuerdatei enthaltenen In- 
formationen der Offset in Byte berechnet wird, an dem 
sich die gewunschten Daten innerhalb der Multimedia- 
Datei befinden, 

daB (6) die codierten Multimedia-Daten als rahrnen- 
weise komprimierte Inhalte danach iiber einen HTTP- 
Request erst ab der durch den Offset spezifizierlen 
Stelle angefordert werden, 

daB aus der Steuerdatei die fur diesen Zeitpunkt darzu- 
stellenden Multimedia-Elemente ermitlelt werden, 
daB (7) festgestellt wird, daB fur diesen Zeitpunkt 
(Rah men) ein neues Bild dargestelk werden soil, 
dafl (8) die benotigten Bilddaten uber das Netz cingele- 
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sen und decodiert werden, 

daB (9) die Bilddaten dabei insbesondere in kleinere ' 
Teilbilder aufgeteiit werden, die gesammelt und ge- 
meinsam iiber die Benutzerschnittstelle GUI darge- 
stellt werden, s 
daB (1 0) festgestellt wird, ob zu diesem Zeitpunkt neue 
Textinformationen dargestellt werden sollen, 
daB die Zeichenkette, deren GroBe in der Steuerdatei 
angegeben ist, iiber das Netz eingelesen und decodiert 
sowie iiber die Schnittstelle GUI angezeigt wird, 10 
daB (11) festgestellt wird, ob zu diesem Zeitpunkt die 
Moglichkeit besteht zu anderen URLs zu verzweigen, 
daB (12) die Adresse fiir die bendtigte Zeichenkette 
iiber das Netz eingelesen und zu einer URL zusammen- 
gesetzt wird, wobei ein vorhandener Browser direkt zu 15 
dieser URL wechselt, wenn der Anwender zu dieser 
Adresse verzweigen will, 

daB (13) die codierten Audio- bzw. Videodaten fiir die 
zeitliche Lange eines Rahmens iiber das Netz eingele- 
sen und anschlieBend decodiert werden, 20 
daB (14) die decodierten Audio- bzw. Videodaten dann 
an einen speziellen Programm-Thread zur Ausgabe di- 
rekt weitergegeben oder gepuffert werden, 
daB dadurch die Prozessierung des nachsten Rahmens 
beginnen kann und zwar solange noch der alte Rahmen 25 
ausgegeben wird, 

daB (15) festgestellt wird, daB zu einem anderen inhalt- 
lichen Abschnitt oder zu einer anderen Bitrate gewech- 
selt werden soli, wobei die Steuerung iiber die Benut- 
zerschnittstelle GUI durch den Anwender erfolgt, 30 
daB (16) gepriift wird, ob noch weitere Multimedia-Da- 
ten (Rahmen) vorhanden sind, die prozessiert und aus- 
gegeben werden konnen und 

daB (17) danach der Multimedia-Stream vollstandig 
ausgegeben wird und das Applet angehalten/beendet 35 
wird. 

10. Verfahren nach einem der vorhergehenden Patent- 
anspriiche, dadurch gekennzeichnet, 

daB bei Live-Streaming die Signaldaten wie Audio-, 
Video-Bildinhalte in Echtzeit codiert werden, 40 
daB die Decodierung iiber einen speziellen. Server er- 
folgt, der die codierten Multimedia-Inhalte dann an an- 
geschlossene Clients, das heifit Java- Applets, ubermit- 
telt, wobei die Daten iiber UDP, TCP (Socket)- oder 
HTTP-Verbindungen iibertragen werden. 45 

11. Verfahren nach Patentanspruch 10, dadurch ge- 
kennzeichnet, 

daB bei UDP- oder TCP- Verbindungen die Daten iiber 
die jeweiligen Verbindungsschnittstellen ausgegeben 
werden und 50 
daB zur Vermeidung einer langeren Blockierung der 
Verbindungsaufbau iiber einen eigenen Thread erfolgt, 
der abbrechbar ist. 
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